Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add (insecure!) Bitcoin headers over DNS support #138

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

petertodd
Copy link
Member

Disabled by default.

Use this with Matt Corallo's https://bitcoinheaders.net/ service.

Disabled by default.

Use this with Matt Corallo's https://bitcoinheaders.net/ service.
@RCasatta
Copy link
Member

Nice!

I understand not providing a default value for the dns-data provider makes sense but citing bitcoinheaders.net in the command help or in the readme would make the user not knowing the strategy able to use it and inform himself/herself

@petertodd
Copy link
Member Author

Yeah, I think before this is actually merged it should be easier to use.

But first, I want to figure out how to make this more secure. It should have some kind of minimum work threshold, or signature check. Matt's service is signed with DNSSEC. But there's no good way to validate DNSSEC signatures client-side.

The issue with a minimum work threshold is for older timestamps you need to validate a lot of headers to get a reasonable amount of total work. ASICs have gotten much better over the years.


addr_bytes = addr.packed

if addr_bytes[0:2] != b'\x20\x01':

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please dont check this, just ignore it. The block header is self-validating by PoW :p

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, that's kinda what I'm doing with that check: if some addresses are added, without the right prefix, they'll be ignored on the off chance that the remaining addresses are a valid block header.

But yeah, I don't actually check PoW in this version of the code so...

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, but I kinda wanted the ability to change the prefix arbitrarily on the server side without it impacting clients.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah! Well, if you're going to do that, you should document that.

@petertodd
Copy link
Member Author

The issue with a minimum work threshold is for older timestamps you need to validate a lot of headers to get a reasonable amount of total work. ASICs have gotten much better over the years.

So difficulty as of Sept 2016, when OpenTimestamps in its current form was released, was 220 billion. Currently it's 64 trillion. So 291 blocks worth of 2016 blocks are equivalent to one block today. Older timestamps do exist, as other timestamps can be converted to OTS format. But they're pretty uncommon. By 2019 difficulty had risen to 6 trillion, which is already ~1/10th of the current difficulty.

In terms of a dollar value, the current 6.25 BTC block reward is worth $230,000 today. So one 2016 era block would cost $790 in terms of lost revenue to make. It's probably good enough to just have a sum difficulty target, and query block headers (in parallel) until that target is reached. One or two current-era blocks is probably fine: for use-cases where someone would actually spend ~$200k to fake some timestamps, you're probably checking more carefully than with DNS anyway.

It also wouldn't be a bad idea to do this via a timeout: fetch as many headers as you can in, say, 5 seconds, even if you've gotten more than the target amount. We can cache headers of course too, so this would help with subsequent validations too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants